Einheit 11 — Sicherheit und Grenzen

Was du nach dieser Einheit weißt: Du weißt, was die Schnittstelle von sich aus schützt, wofür du selbst verantwortlich bleibst, und wo die textbasierte Arbeit endet.

Was der Server schützt

Geheimnisse werden nicht herausgegeben

Sowohl workflow_show als auch workflow_export schwärzen Geheimnisse:

"options": {
  "form_fields": "[{\"name\":\"freitext\", …}]",
  "response_text": "Danke - die Anfrage wird verarbeitet.",
  "secret": "[REDACTED]"
}

Das gilt auch für dich selbst — der Server liefert den Wert nicht aus, egal wer fragt.

Für die Praxis heißt das: Ein Export ist unbedenklich weiterzugeben. Genau das war in Kurs 5, Einheit 2 die Begründung für die zentrale Credentials-Verwaltung. Über MCP wird sie doppelt wichtig, weil Exporte hier mit einem Satz entstehen und in einer KI-Sitzung landen.

Zugangsdaten sind nur Namen

credential_list gibt ausschließlich Namen zurück, nie Werte. Anlegen und Ändern geht nur in der Oberfläche. Der Assistent kann @secret(Pipedrive_token) schreiben, aber den Token selbst nie sehen.

Die Rechte sind deine

Der MCP-Token bindet an deinen Benutzer. Du siehst deine Projekte, deine Workflows, deine Zugangsdaten. Eine Rechteausweitung gibt es nicht — aber eben auch keine Einschränkung: Der Assistent kann alles, was du kannst.

Wofür du verantwortlich bleibst

Der Assistent handelt, er schlägt nicht vor

workflow_delete löscht. workflow_run löst echte Aktionen in echten Zielsystemen aus. agent_update überschreibt Konfigurationen. Es gibt keine Bestätigungsstufe auf Serverseite.

Der Satz, der weh tut

„Räum die alten Testworkflows auf" ist eine mehrdeutige Anweisung. Was „alt" und was „Test" ist, entscheidet dann jemand anderes als du — und es gibt keinen Papierkorb.

Sag, welchen Workflow du meinst. Nenne die ID.

Claude Code fragt bei verändernden Werkzeugen um Erlaubnis. Lies, was in der Rückfrage steht — insbesondere die Workflow-ID. Dauerfreigaben („immer erlauben") sind für Lesewerkzeuge sinnvoll und für workflow_delete eine schlechte Idee.

Daten verlassen deine Instanz

Alles, was ein Werkzeug zurückliefert, geht in den Kontext des Assistenten — und damit an den Modellanbieter. Das betrifft insbesondere:

• workflow_messages und agent_messages — echte Nachrichteninhalte, also womöglich Kundendaten, Rechnungspositionen, Personendaten
• agent_logs — gerenderte Prompts und vollständige Request-Bodies
• workflow_export — die komplette Konfiguration

Die Geheimnis-Schwärzung greift bei Optionen, nicht bei Nachrichteninhalten. Ein personenbezogener Datensatz, der durch deinen Workflow fließt, steht in agent_messages im Klartext.

Vor dem Log-Abruf kurz nachdenken

Debugge produktive Workflows mit echten Personendaten bevorzugt mit einem Testdatensatz, den du selbst eingespeist hast. Wenn das nicht geht, hol gezielt einzelne Agents ab statt pauschal 200 Nachrichten — und kläre vorher, ob euer Datenschutzkonzept diesen Weg abdeckt.

Der Token ist ein Zugang

Der MCP-Token steht im Klartext in ~/.claude.json. Behandle die Datei wie eine Passwortdatei: nicht ins Repository, nicht in einen geteilten Ordner, nicht in einem Screenshot. Bei Verdacht: in 42°flow neu erzeugen, alten ungültig machen.

Wo die Schnittstelle endet

Diese Dinge kann MCP nicht — dafür brauchst du weiterhin die Oberfläche:

Aufgabe	Wo
Zugangsdaten anlegen oder ändern	Oberfläche
Benutzer und Rollen verwalten	Oberfläche (Modul 2)
Projekte anlegen	Oberfläche
UI Apps bauen	Oberfläche (Modul 5)
Canvas ansprechend anordnen	Oberfläche (agent_update kann nur Koordinaten setzen)
Formular- und Freigabe-Oberflächen ansehen	Browser
Den Workflow jemandem erklären	Canvas

Dazu kommen die Eigenheiten, die du kennen solltest:

• towelscript_format formatiert nicht — es gibt den Quelltext unverändert zurück. Einheitliche Formatierung ist eine Team-Konvention, kein Werkzeug.
• agent_test_run löst Aliasnamen bei virtuellen Agents nicht auf — agent_type verwenden.
• TowelScript kennt keine Positionen — jeder frische Deploy braucht einmal Handarbeit im Canvas.

Eine Arbeitsweise, die trägt

Regel	Grund
Testprojekt für Experimente	Produktivworkflows nicht als Spielwiese
Vor jedem Löschen exportieren	Kein Papierkorb
IDs nennen statt „die alten"	Mehrdeutigkeit ist irreversibel
Quelltext in Git, Token nicht	Änderungen nachvollziehbar, Zugang geschützt
Lesewerkzeuge dauerfreigeben, schreibende nicht	Reibung dort, wo sie nützt
Beim Debuggen Testdaten statt Echtdaten	Nachrichteninhalte gehen in den Modellkontext
Ergebnis selbst prüfen	workflow_show und graph kosten Sekunden

Der letzte Punkt ist der wichtigste. Der Assistent arbeitet schnell und meistens richtig. „Meistens richtig" ist bei einem Workflow, der Rechnungen verarbeitet, nicht gut genug. Die Verantwortung für das Ergebnis bleibt bei dir — genau wie bei einem Workflow, den du selbst zusammengeklickt hast.

Zusammengefasst

Der Server schützt	Geheimnisse in Optionen, Credential-Werte, Rechtegrenzen
Du schützt	Nachrichteninhalte, den Token, die Eindeutigkeit deiner Anweisungen
Die Oberfläche bleibt zuständig für	Zugangsdaten, Benutzer, Projekte, UI Apps, Layout

Weiter: Einheit 12 — Referenzkarte